我相信應該很常遇到以下情境

新功能開發都完成了，測試後覺得都沒問題，然後就直接正式上線了
但上線後，不斷收到用戶反應 「某操作導致按鈕無法送出」、「某權限的用戶無法進到該頁面」 等等

上述中有個重要的觀點可以思考一下

「測試後覺得沒問題」

所以到了【測試階段】，才會去 確認/驗證/測試 有產品會怎麼樣？

先簡單說明下，大部分的開發周期都是

需求規劃 → 設計 → 工程實作 → 測試 → 上線

同時上篇文章 開發團隊常說的品質到底是什麼？ 有說到

品質是開發流程

所以若真的都是到 【測試階段】 才去確認產品功能

當真正發生問題時，這個開發的成本會變得很高，因為中間會有很多修改、會議、確認、討論、實作等等要一直反反覆覆的執行。

那就真的會爆炸XDD

但在現實層面，往往在這種情況下，因為迫於時程壓力，可能選擇犧牲很多品質。

所以好的品質不應該是只在產品上線前一刻用【測試】的方式去確保品質的

品質應該會在開發周期的最前面就開始準備了

• 在開發前期，就開始確認需求、確認開發流程、確認專案時程、規劃測試計畫 等

• 在開發中期

  • 開發工程師們一邊撰寫的 code 一邊盡量寫多寫些單元測試
  • QA 也開始準備執行先前規劃的測試計畫，可同時撰寫系統整合測試、UI/API 自動化測試、效能測試等等。

• 在開發後期，就能將先前寫的測試腳本直接進行測試

• 上線後，也需持續觀察用戶使用情況

上述這些做法，都是為了盡量降低開發成本及風險。

所以 品質 ≠ 測試，但是品質中卻又包含了測試

必須得說，【測試】也確實在品質中佔有一席之地

主要我會把【測試】更看作是【提升品質】的方式之一

那你也就會知道，測試其實並也不是只有 QA 或 測試人員 要做的事情。

我會把【測試】解讀成【為了讓這個產品/功能更加卓越，更加穩定，所以我用盡了各種方式進行確保】

總結

那整體串下來就會知道，原來品質應該是在開發流程的源頭就要開始進行了

同時這也是為了預防各種可能會出現的問題 及 盡量降低問題的嚴重性

現實中的品質確實很難達到滿分的，但我們能做的是讓它慢慢變得更好。

所以如果整個開發團隊都對【品質】是有共識的，且都有一致的目標，那這樣產品一定也會越來越好，開發流程也會越來越順。

我們能做的就是提早發現問題，提早解決，盡量避免後續出現的問題

有句話是，羅馬不是一天造成的

好的品質也不是一天就能造成的，是產品必須透過不斷的迭代更新，來逐漸改善品質，讓它越來越好

參考資料:

• [所以我說 Google 你的測試] 品質到底是什麼？